home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Sep 90 / MacApp.Tech$ 9⁄7⁄90 / 1916-Re Drawing Problem S-Sep90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.4 KB  |  57 lines  |  [TEXT/GEOL]
  1. Item    6273197                         5-Sept-90        10:25PDT
  2.  
  3. From:   KNEPPER                         Knepper, Christopher
  4.  
  5. To:     PEMD                            CH DEV PEMD Group, Zurich,IDV
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: Drawing Problem Solved
  10.  
  11. Ernie,
  12.  
  13. >I strikes me as a bit strange that the default focus should be the last window
  14. >drawn rather than the front, active window.  Does it also seemed that way to
  15. >you?
  16.  
  17. I don't think it's so much a question of the default focus being the last
  18. window drawn, rather I think it's a question of always focusing before drawing.
  19. When the windows are refreshed front-to-back, the last window is the one that
  20. is last drawn, and therefore, since it was last drawn, it is the one last
  21. focused (in TView.DrawContents) and that is the one that is the "default"
  22. focus.
  23.  
  24. However, I don't think that you should think in terms of a "default" focus,
  25. rather I think that you need to think in terms of:
  26.   "always focus before drawing"
  27. Rather than,
  28.   "where was the focus last set" or
  29.   "always focus before dispatching a menu command"
  30.  
  31. If you take this philosophy, you'll get much further than trying to figure out
  32. where the "default" or "last" focus was set, or trying to figure out if a menu
  33. command could potentially cause drawing to occur and therefore requires
  34. focusing before dispatching the menu command.
  35.  
  36. Finally, I would like to differ with you as to your solution. I think that you
  37. need to "always focus before drawing" rather than focusing in
  38. "myView.DoMenuCommand" which is sort of like "always focus before dispatching a
  39. menu command". Although the effect may be the same, the philosophy of
  40. programming is quite different, and I think that it breaks the
  41. object-orientedness of your code.
  42.  
  43. The best solution of all would be to have a menu command not perform any
  44. drawing at all, but instead to have it change the model (the TDocument, by
  45. default) and then ask document to render the changed model, notifying the view
  46. imaging the model (myView) to redraw its contents as necessary. The advantage
  47. of this approach is that it removes drawing from the menu command, and sticks
  48. it in the view (where it belongs).
  49.  
  50. If you take this approach, then the drawing is done by "myView.Draw()" and
  51. you're gauranteed to be focused when that gets called (by DrawContents), so the
  52. problem of figuring out when/where to focus is greatly reduced, if not
  53. eliminated all together.
  54.  
  55. -Chris
  56.  
  57.